home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 7 / BBS in a Box - Macintosh - Volume VII (BBS in a Box) (January 1993).iso / Files / Tele / W-Z / Watson Xfer Test.cpt / Watson‘s XFer Tests.TXT
Text File  |  1989-12-02  |  8KB  |  176 lines
  1. Msg#   : 3876   Mon 27 Nov 89 11:28p
  2. From   : Scott Watson
  3. To     : All
  4. Subject: White Knight Benchmarks....
  5. Status :
  6. --------------------------------------------------------------------------
  7. I was pleased to have the opportunity to review Bob Nordling's time
  8. trials between ZTerm 0.85 and White Knight 11.  This is the sort of thing
  9. that needs to be done and I applaud Bob for taking the initiative.
  10.  
  11. One thing I want to point out is that Bob's trials might not be accurate,
  12. because of his hardware setup while doing the tests. I'd like to explain
  13. where problems can creep in that will compromise the integrity of the
  14. test.
  15.  
  16. In order to benchmark the efficiency of a communications program, you
  17. must first remove anything that is not a part of what is being measured.
  18. Bob used modems connected through voice grade telephone lines, and this
  19. in itself can add a sufficient amount of "noise" to make the test
  20. statistically invalid.
  21.  
  22. Here's why.  First of all, you are not only measuring the speed of the
  23. communications software, but are also getting the additive effects of the
  24. telephone company network turnaround time and inconsistant noise on these
  25. lines.  Additionally, you are adding the efficiency of the modem, which
  26. believe it or not, does change significantly from brand to brand (but
  27. that's a story for a different winter's evening).
  28.  
  29. Even on those modems that offer error-correction, there can be bursts of
  30. garbage that cause retransmissions invisible to the tester.  In fact, a
  31. modem that uses MNP error correction without any modem level data
  32. compression can actually be less efficient on a clean line than two
  33. modems doing no error correction (due to the added overhead of the
  34. error-correction data).  On a line that experiences occasional or
  35. frequent noise, however, the MNP modems will be more efficient than those
  36. modems that leave error-detection/correction up to the communications
  37. software.
  38.  
  39. There's a whole world of "gotcha's" that can destroy the intended truths
  40. of a benchmark, and you'll see that I've tried (albeit not perfectly, I'm
  41. sure, but at least to the point of practical consistency) to remove these
  42. from my tests.
  43.  
  44. During the development of White Knight, I was constantly bench- marking
  45. against other communications software, and Bob's results didn't mirror my
  46. own.
  47.  
  48. Therefore, in the spirit of furthering what Bob started, I decided to
  49. publish my own test results.  As you can see, I went to great lengths to
  50. maintain consistency on the tests so that the results can be viewed in
  51. the proper light of comparison.
  52.  
  53. A final note.  These numbers should not be used to say that one program
  54. is necessarily better than another.  The overall quality and value of the
  55. software tested goes way beyond what these tests attempt to measure.  I
  56. appreciate all comments about these tests, and certainly encourage
  57. further tests and confirmation attempts.
  58.  
  59. Benchmarks Between White Knight 11.01, ZTerm 0.85 & MicroPhone II
  60. -----------------------------------------------------------------
  61.  
  62. Tests were performed on a Macintosh II running at factory speed.
  63.  
  64. System software was Finder 6.1.4 and System 6.0.4.  All INIT's were
  65. removed from the System Folder and the machine restarted.
  66.  
  67. Tests were performed under Finder (not MultiFinder) for purposes of
  68. consistency and to eliminate background tasks of unknown duration.
  69.  
  70. Software resided on and all file transfers were saved to a 40 megabyte
  71. hard disk drive.  Each received file was erased before the next test so
  72. that the file would be saved to the same sectors on the hard disk and
  73. fragmentation of the disk wouldn't be a factor.
  74.  
  75. The RAM cache was turned off.
  76.  
  77. All tests were performed at 9600 baud via a null modem cable direct
  78. connection to eliminate delays from telephone line quality or modem
  79. performance.
  80.  
  81. All tests were performed with Apple's Alarm Clock desk accessory open,
  82. which was used for time measurement to the nearest second.  Sample runs
  83. with this desk accessory closed did not show any significant change in
  84. times.  Tests should be considered to be accurate to plus or minus 1.5
  85. seconds and I was diligent to keep them as near true as possible.
  86.  
  87. Each test was run three times in a row.  This was to eliminate delays
  88. from loading in CODE and/or other resources.  This proved to be a
  89. significant step, as nearly all second times were better than the first,
  90. and all third times were about the same as the second.  The third test
  91. times are what are given below.
  92.  
  93. Software versions:
  94. (These may or may not be the "latest" versions, but were the latest
  95. available to me at the time of the test)
  96. White Knight 11.01
  97. ZTerm 0.85
  98. Microphone II version 2.0
  99.  
  100. TEST #1: VT Terminal Emulation
  101. ------------------------------
  102. The sending machine was a Mac SE with 1 megabyte of memory.  A special
  103. program was written to send the data.  This program placed the entire
  104. file into the serial driver buffer and sent it asynchronously, supporting
  105. XON/XOFF flow control.  This special program was written to provide
  106. consistency, and to eliminate delays caused by the sending software.  It's
  107. available on request for those who wish to duplicate these tests.
  108.  
  109. The file sent was a capture of an entire session on Digital Equipment
  110. Corporation's Electronic Store (Phone number: 1-800-DEC-DEMO) and
  111. was 28,540 bytes long.
  112.  
  113. Timing was done from the first character displayed to the last character
  114. displayed.  All times given are in seconds.
  115.  
  116. White Knight      ZTerm       MicroPhone II
  117. ------------      -----       -------------
  118.      31            32              32
  119. Conclusion: The disparity between White Knight and the other two programs
  120. might be attributable to operator timing error and should not be taken as
  121. significant.  All programs operated equally well.
  122.  
  123. TEST #2: Straight Text Receive
  124. ------------------------------
  125. The sending machine and software used was the same as in TEST #1.  The
  126. file was a 9,729 byte file containing lines of text only (no emulation
  127. sequences).  This test was done to compare scrolling speeds.  Times are
  128. given in seconds.
  129.  
  130. White Knight      ZTerm       MicroPhone II
  131. ------------      -----       -------------
  132.      17            18              23
  133. Conclusion: No significant difference between White Knight and ZTerm.
  134. MicroPhone II's performance would seem to indicate significance.
  135.  
  136. TEST #3: XMODEM File Receive
  137. ----------------------------
  138. In this test, the sending machine was a Macintosh SE running White Knight
  139. 11.01.  The file sent was a MacBinary format file with 0 bytes in the
  140. data fork and 67,893 bytes in the resource fork.  Between each test, the
  141. file was deleted from the receiver's disk to avoid delays due to
  142. overwriting
  143. or renaming the file.  XMODEM with CRC error checking was used, with 128
  144. byte blocks.  If the programs reported the final elapsed time (which was
  145. true of White Knight and ZTerm), that time was verified against a manual
  146. timing and found to be consistent.  Therefore, those times are given.
  147. Otherwise, the timing was done from the first indication of
  148. a received byte to the first notification that the transfer had ended.
  149. Times are given in minutes and seconds.
  150.  
  151. White Knight      ZTerm       MicroPhone II
  152. ------------      -----       -------------
  153.     1:43          2:07             1:59
  154.  
  155. Conclusions: All times would appear to have significance compared to
  156. the others.
  157.  
  158. TEST #4: ZMODEM File Receive
  159. ----------------------------
  160. The conditions in TEST #3 were duplicated precisely, except the file was
  161. sent using standard ZMODEM protocol.  Times are given in minutes and
  162. seconds.
  163.  
  164. White Knight      ZTerm       MicroPhone II
  165. ------------      -----       -------------
  166.     1:23          1:24        Protocol Not Available
  167. Conclusion: Times between White Knight and ZTerm would not appear to
  168. be significant.  It should be noted that MicroPhone has announced the
  169. inclusion of ZMODEM protocol in their forthcoming version 3.0, but that
  170. version was not available at the time of the test.  I hope to update
  171. this chart when it has become available.
  172.  
  173. Scott Watson
  174.  
  175. --- Tabby 2.1
  176.  * Origin: MacInfo BBS - Newark, CA.  @415-795-8862 (HST)RRH (1:204/555)